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SPECIFICATIONS  FOR  THREE  MEMBERS  OF  THE 
MILITARY  MESSAGE  SYSTEMS  (MMS)  FAMILY 


Introduction 

Contained  herein  are  informal  specifications  for  the  user  commands  supported  by  three 
message  systems,  namely,  MO,  Ml,  and  M2,  all  members  of  the  Military  Message  System 
(MMS)  family.  We  call  the  specifications  informal  because  the  semantics  of  each  user  com¬ 
mand,  i.e.,  the  command’s  user-visible  effects,  are  described  in  English  prose.  A  future  report 
will  provide  more  formal  specifications. 

This  document  is  divided  into  four  sections:  Section  1  provides  an  overview  of  the  MMS 
family  and  the  three  family  members;  Section  2  lists  the  user  commands;  Section  3  contains 
specifications  for  the  user  commands;  and  Section  4  provides  a  glossary. 

1.  Overview  of  MMS  Family  and  Three  Family  Members 

After  introducing  MMS  terminology,  this  section  describes  the  Intermediate  Command 
Language  (ICL)  and  its  role  in  the  specifications;  the  relationship  between  the  specifications  and 
the  MMS  security  model  [l];  and  specific  requirements  of  the  three  MMS  family  members. 

1.1.  MMS  Terminology 

A  MMS  user  issues  commands  to  log  into  and  out  of  the  system  and  to  perform  various 
operations  on  MMS  data  items.  There  are  two  major  classes  of  MMS  data  items:  users  and 
entities.  A  user  is  a  person  authorized  to  use  the  MMS.  Associated  with  each  user  are  three 
attributes:  the  user’s  clearance,  a  set  of  authorised  roles  (e.g.,  downgrader,  releaser,  system 
security  officer),  and  a  set  of  current  roles.  Examples  of  entities  are  messages  and  message 
files.  Associated  with  each  entity  are  four  attributes:  the  entity  classification  (e.g.,  SECRET), 
its  value,  its  data  type  (which  determines  the  kinds  of  operations  that  can  be  applied  to  the 
entity),  and  its  access  set  (which  describes  the  operations  that  specified  users  may  perform  on 
the  entity).  Some  entities,  called  containers,  may  have  an  additional  attribute,  called  Con¬ 
tainer  Clearance  Required  (CCR),  that  requires  any  user  who  wishes  to  view  information  in 
the  container  to  have  a  clearance  greater  than  or  equal  to  the  classification  of  the  container.  In 
a  MMS,  a  userlD  is  a  name  for  a  user  and  a  reference  is  a  name  for  an  entity. 

Each  MMS  user  is  assigned  a  special  message  file,  called  an  inbox,  in  which  the  MMS 
places  an  entry  for  each  message  sent  to  the  user.  An  entry  contains  the  message  and  message 
status  information  (e.g.,  whether  the  message  is  “new”,  whether  the  message  was  received  “for- 
action”,  “for-info”,  etc.).  When  the  user  displays  his  inbox  or  any  other  message  file,  only  part 
of  each  message  entry  in  the  file  is  displayed.  The  part  consists  of  selected  message  fields  (e.g., 
the  Subject  and  To  fields  of  the  message)  and  the  message  status  information. 

Every  message  is  either  a  draft  message  or  a  sent  message.  A  draft  message  is  a  message 
in  draft  form;  users  create  and  edit  draft  messages.  A  sent  message  is  a  message  that  has  been 
released,  i.e.,  sent  to  one  or  more  other  users.  By  issuing  the  command  SEND_MSG,  the  user 
converts  a  draft  message  into  a  sent  message.  A  user  may  send  messages  to  local  users,  i.e., 
users  on  the  same  MMS,  or  to  remote  users,  i.e.,  users  on  different  message  systems.  For  each 
remote  user  to  whom  a  message  is  sent,  the  MMS  may  transmit  a  copy  of  the  message  over  the 
appropriate  network.  For  each  local  user,  the  MMS  creates  an  entry  for  the  message  and 
inserts  the  entry  into  the  user’s  inbox. 

Every  message  has  a  message  type.  Many  family  members  support  two  message  types: 
formed  messages  and  informal  messages.  The  message  type  is  determined  at  the  time  the  mes¬ 
sage  is  created.  When  a  user  issues  the  SEND_MSG  command,  thus  converting  a  message  from 
a  draft  to  a  sent  message,  the  message  type  does  not  change.  Messages  of  two  different  message 
types  can  differ  (1)  in  the  set  of  fields  that  they  contain  and  (2)  in  the  set  of  ICL  commands 
that  can  be  applied  to  them. 
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1.2.  Intermediate  Command  Language 

An  important  feature  of  this  document  is  use  of  an  Intermediate  Command  Language 
(ICL)  to  describe  the  set  of  functions  that  MMS  family  members  perform.  The  ICL  is  designed 
so  that  the  functions  supported  by  any  single  family  member  can  be  described  by  some  ICL  sub¬ 
set.  The  ICL  subsets  associated  with  MO,  Ml,  and  M2  are  listed  in  Section  2. 

The  specific  form  a  user  command  takes  can  vary  from  family  member  to  another.  For 
example,  a  user  command  to  display  a  message  may  take  any  one  of  the  following  forms: 

•  the  user  types  the  string  “display  message” 

•  the  user  types  the  string  “show  message” 

•  the  user  selects  the  menu  item  “DISPLAY  MESSAGE” 

•  the  user  depresses  a  function  key  labeled  “DISPLAY  MESSAGE” 

Such  syntactic  differences  are  not  reflected  in  the  ICL.  Each  ICL  command  is  an  abstract 
description  of  a  user  command  in  that  it  specifies  the  command’s  user-visible  effects  without 
imposing  unnecessary  restrictions  on  either  the  command  syntax  or  the  physical  characteristics 
of  the  user’s  terminal.  Thus,  if  the  effect  of  each  of  the  above  user  commands  is  identical,  i.e., 
each  causes  the  user  terminal  to  display  the  specified  message,  each  user  command  is  associated 
with  the  same  ICL  command,  namely,  DISPLAY_MSG. 

The  ICL  treats  the  editing  of  some  MMS  entities  and  all  access  sets  in  the  following  spe¬ 
cial  way.  To  initiate  editing,  the  user  issues  the  command  EDIT_XX,  where  XX  is  the  data 
type  of  the  item  to  be  edited.  EDIT_XX  returns  a  copy  of  the  item,  and  the  user  then  applies 
various  non-ICL  commands  (i.e.,  editing  commands)  to  modify  the  item  as  he  desires.  Once  the 
user  is  satisfied  with  the  edited  version,  he  issues  an  UPDATE_XX,  which  changes  the  value  of 
the  item  to  that  of  the  edited  version.  If  the  user  is  not  satisfied  with  the  edited  version,  he  can 
omit  issuing  the  UPDATE_XX  command,  thus  retaining  the  item’s  original  value. 

1.3.  MMS  Security  Model 

A  MMS  is  required  to  enforce  the  rules  of  the  MMS  security  model  [l].  Thus  a  MMS  must 
begin  operation  in  a  secure  state,  where  secure  state  is  as  defined  in  the  model.  Each  time  a 
user  issues  an  ICL  command,  one  or  more  changes  in  system  state  can  occur.  However,  these 
state  changes  can  occur,  i.e.,  the  ICL  command  can  be  completed,  only  if  the  constraints  of  the 
security  model  are  satisfied.  One  immediate  consequence  of  enforcing  the  MMS  security  model 
is  that  each  ICL  command  that  displays  the  value  of  a  MMS  entity  must  also  display  the 
entity’s  classification.  Thus,  in  the  specifications  below,  all  ICL  commands  that  display  an 
entity  value  have  at  least  two  output  parameters:  a  value  and  a  classification. 

The  MMS  security  model  requires  that  all  entities  of  a  given  type  be  treated  as  either 
objects  or  containers.  An  object  is  the  smallest  unit  in  the  MMS  that  has  a  classification;  it 
contains  no  other  objects  and  cannot  be  multilevel.  In  contrast,  a  container  has  a 
classification  but  may  contain  objects  and/or  other  containers  each  with  its  own  classification. 
In  a  MMS,  the  Subject  and  To  fields  of  a  message  are  usually  objects,  while  messages,  message 
files,  and  text  files  are  usually  containers. 

1.4.  Specific  Requirements 

The  purpose  of  this  report  is  to  provide  specifications  for  three  MMS  family  members.  The 
first,  MO,  supports  the  display  and  storage  into  message  files  of  incoming  messages.  The  second 
system,  Ml,  includes  all  user  commands  of  MO  and  additional  commands  for  the  composition 
and  transmission  of  outgoing  messages.  The  third  system,  M2,  is  an  extension  of  Ml,  providing 
user  commands  for  the  system  security  officer  as  well  as  commands  for  specifying  discretionary 
access  controls  on  messages  and  other  MMS  data  items. 

Indicated  in  Table  1  are  specific  requirements  of  MO,  Ml,  and  M2,  namely,  which  entities 
are  containers,  which  entities  are  objects,  which  containers  have  the  CCR  attribute,  and  which 
message  types  are  implemented.  We  note  that  the  first  three  items  in  the  table  are  part  of  the 


“interpretation”  of  the  security  model,  since  they  define  the  mapping  from  abstract  concepts  of 
the  security  model  to  the  concrete  data  items  of  MO,  Ml,  and  M2. 


Table  1.  Specific  Requirements  of  MO,  Ml,  and  M2 


MO 

Ml 

M2 

Which  entities  are 

terminals 

terminals 

terminals 

containers? 

messages 
message  files 
message  file 
directory 

messages 
message  files 
message  file 
directory 

messages 
message  files 
message  file 
directory 
text  files 
text  file 
directory 

Text  field  of 
message 
message  entries 

Which  entities  are 
objects? 

all  others 

all  others 

all  others 

Are  there  any  non- 
CCR  containers? 

no 

no 

some  message  files 
may  be  non-CCR; 
all  directories 
and  all  output 
devices  are 
non-CCR;  all 
other  containers 
are  CCR 

What  message  types 
are  supported? 

informal 

informal 

informal  and  formal 

2.  ICL  Subsets  for  MO,  Ml,  and  M2 

This  section  contains  two  lists  of  the  ICL  commands  associated  with  MO,  Ml.  and  M2,  one 
organized  by  data  type,  the  other  by  generic  command  name.  Both  lists  are  based  on  the  fol¬ 
lowing  seven  data  types:  message,  message  file  message  file  directory,  text  file,  text  file  directo¬ 
ry,  terminal,  and  user.  (Because  there  are  relatively  few  ICL  commands,  such  as  DELETEME 
and  COPYME,  that  operate  on  message  entries  and  because  each  such  command  can  cause  a 
modification  in  a  message  file,  we  include  these  commands  under  the  data  type  “message  file”.) 
The  Appendix  contains  a  third  list  of  the  ICL  commands  organized  alphabetically. 

2.1.  Organisation  by  Data  Type 

The  list  below  indicates  the  ICL  commands  associated  with  each  of  the  three  family 
members  and  provides  the  location  of  each  command’s  specification.  In  the  list,  all  ICL  com¬ 
mands  defined  on  the  same  data  type  are  grouped  together. 


v~\  v  v~'. 
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MO 


DISPLAY31SG 


CREATE_MF 

DESTROY_MF 

DISPLAY_MF 

DELETEME_MF 

UNDELETEME_MF 

EXPUNGE3IF 

C0PY\1E_MF 

MOVEME3IF 


DISPLAY31FD 


Commands  on  Messages 


Ml 

M2 

Where  Specified 

CREATE3ISG 

CREATE3ISG 

3.8.1 

EDIT3ISG 

EDIT_MSG 

3.2.4 

UPDATE31SG 

UPDATE_MSG 

3.2.5 

DISPLAY31SG 

DISPLAY31SG 

3.2.2 

SEND3ISG 

SEND3ISG 

3.8.2 

REPLY3ISG 

REPLY3ISG 

3.9.1 

FORINFO_MSG 

F0RINF031SG 

3  9.2 

PRINT31SG 

3.2.3 

F0RC00RD3ISG 

3.10.1 

F0RACTI0N31SG 

3.11.1 

F0RRELEASE3ISG 

3.10.2 

READDRESS3ISG 

3.11.2 

DUP31SG 

3.7.1 

DISPLAYAS3ISG 

3.2.7 

PRINTAS31SG 

3.2.8 

EDITAS31SG 

3.2.9 

UPDATEAS3ISG 

3.2.10 

Commands  on 

Message  Files 

CREATE3IF 

CREATE3IF 

3.3.1 

DESTR0Y3IF 

DESTR0Y3IF 

3.2.1 

D1SPLAYJMF 

DISPLAY34F 

3.3.2 

DELETEME3IF 

DELETEME3IF 

3.3.4 

UNDELETEME3IF 

UNDELETEME31F 

3.3.5 

EXPUNGE31F 

EXPUNGE3IF 

3.3.6 

C0PYME3IF 

C0PYME31F 

3.3.7 

M0VEME3IF 

MOVEME3IF 

3.3.8 

RECLASSIFY31F 

RECLASSIFY3IF 

3.2.6 

DUPJAF 

3.3.9 

PRINT31F 

3.3.3 

DISPLAYAS3IF 

3.2.7 

PRINTAS3IF 

3.2.8 

EDITAS3IF 

3.2.9 

UPDATEAS3IF 

3.2.10 

Commands  on  Message  File  Directories 

DISPLAY3IFD 

DISPLAY3IFD 

3.5.1 

PRINT3tFD 

3.5.2 

DISPLAY AS3IFD 

3.2.7 

PRINTAS3TFD 

3.2.8 

EDITAS3IFD 

3.2.9 

UPDATEAS31FD 

3.2.10 

Commands  on  Text  Files 


MO  Ml  M2 

CREATE.TF 

DESTROY.TF 

EDIT_TF 

UPDATE.TF 

DISPLAY.TF 

PRINT.TF 

COPYFRENT_TF 

COPYTOENT.TF 

RECLASSIFY_TF 

DUP_TF 

DISPLAYAS_TF 

PRINTAS.TF 

EDITAS.TF 

UPDATEAS.TF 


Commands  on  Text  File  Directories 


DISPLAY.TFD 

PRINT_TFD 

DISPLAYAS.TFD 

PRINTAS_TFD 

EDITAS_TFD 

UPDATEAS.TFD 


Commands  on  Terminals 


CREATE.TERM 

DESTROY.TERM 

DISPLAY.TERM 

PRINT_TERM 

RECLASSIFY.TERM 

MAXCLAS_TERM 


Commands  on  Users 


CREATE.USER 

DESTROY_USER 

DISPLAY.USER 

PRINT.USER 

CHGCLEAR_USER 

CHGPW.USER 

ADDAROLEJJSER 

RMVAROLEJJSEF 

ADDCROLE_USER 

RMVCROLEJJSER 

LOGIN.USER  LOGINJJSER  LOGIN_USER 

LOGOUTJJSER  LOGOUTJJSER  LOGOUTJJSER 


Where  Specified 

3.4.1 

3.2.1 

3.2.4 

3.2.5 

3.2.2 

3.2.3 

3.4.2 

3.4.3 

3.2.6 

3.4.4 

3.2.7 

3.2.8 

3.2.9 

3.2.10 


3.5.1 

3.5.2 

3.2.7 

3.2.8 

3.2.9 

3.2.10 


3.6.1 

3.2.1 

3.6.2 

3.6.3 
3.2.6 

3.6.4 


3.12.1 

3.12.2 

3.12.3 

3.12.4 

3.12.5 

3.12.6 

3.12.7 

3.12.8 

3.12.9 

3.12.10 

3.12.11 

3.12.12 


2.2.  Organisation  by  Generic  Command  Name 

ICL  commands  with  the  same  or  similar  meanings  share  the  same  generic  command  name. 
In  some  cases,  two  commands  with  the  same  generic  name  have  identical  semantics  (e.g., 
RECLASSIFY3IF  and  RECLASSIFY_TERM).  In  other  cases,  two  commands  with  the  same 
generic  name  have  somewhat  different  semantics  (e.g.,  DISPLAY_MF  and  DISPLAY_MFD). 
Table  2  lists  the  generic  command  names,  indicates  the  data  types  for  which  each  generic  com¬ 
mand  is  defined,  and  provides  the  location  of  the  specification  of  the  ICL  command  with  the 
given  generic  command  name  and  data  type.  A  blank  table  entry  indicates  that  the  generic 
command  is  not  defined  on  the  given  data  type. 

In  Table  2,  related  generic  commands  are  listed  together.  Commands  may  be  related  be¬ 
cause  they  are  inverses  (e.g.,  CREATE  and  DESTROY),  because  their  semantics  are  similar 
(e.g.,  DISPLAY  and  PRINT),  or  because  they  are  usually  invoked  sequentially  (e.g.,  EDIT  and 
UPDATE). 

Table  2:  ICL  Commands  Organized  by  Generic  Command  Name 


g 


m 


COMMAND 

MSG 

MF 

TF 

MFD 

TFD 

TERM 

USER 

CREATE. 

3  8.1 

3.3.1 

3.4.1 

3.6  1 

3.12.1 

DESTROY. 

3.2.1 

3.2.1 

3.2.1 

3.12.2 

DISPLAY. 

3  2  2 

33  2 

3.2.2 

35.1 

3.5.1 

3  6.2 

3.12.3 

PRINT. 

3.2  3 

333 

32.3 

3.5.2 

3.5.2 

3  6.3 

3  12  4 

EDIT. 

3  2.4 

32  4 

UPDATE. 

3  2.5 

3.2.5 

DELETEME. 

334 

UNDELETEME. 

33  5 

EXPUNGE. 

33.6 

COPYME. 

3.37 

MOVEME. 

338 

COPYFRENT. 

342 

COPYTOENT. 

343 

DUP. 

3.7  1 

33  9 

3.4.4 

RECLASSIFY. 

3.2  6 

3.2  6 

3  2  6 

MAXCLAS. 

3.64 

SEND. 

3.8  2 

READDRESS. 

3  112 

REPLY. 

39  1 

FORINFO. 

39  2 

FORACTION. 

3  11  1 

FORCOORD. 

3  10  1 

FORRELEASE. 

3  10  2 

DISPLAYAS. 

3  2  7 

3.2.7 

32.7 

3.2.7 

3.2.7 

PRINTAS. 

3  2  8 
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3  2  8 

3.2.8 

32.8 

EDITAS. 

3  2  9 

3  2  9 

3  2  9 

3.2.9 

3  2  9 

UPDATEAS. 

3  2  10 

3  2  10 

3.2.10 

3.2.10 

3.2  10 

CHG CLEAR. 

3.12  5 

CHGPW. 

3  12  6 

ADDAROLE. 

3  12  7 

RMVAROLE. 

3  12  8 

ADDCROLE. 

3  12.9 

RMVCROLE. 

3  12.10 

LOGIN. 

3  12.11 

LOGOUT 

3  12  12 

I 
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3.  Command  Specifications 

3.1.  Introduction 

This  section  contains  specifications  for  each  ICL  command  listed  in  Section  2.  The 
specifications  are  modifications  of  earlier  work  [2]. 

3.1.1.  Data  Type  Hierarchy 

The  set  of  ICL  commands  can  be  partitioned  into  two  smaller  sets:  the  first  contains  com¬ 
mands  associated  with  entities  (e.g.,  UPDATE_MSG),  the  second  commands  associated  with 
users  (e.g.,  CREATE_USER).  The  specifications  of  many  commands  in  the  first  set  differ  only  in 
the  data  types  of  their  parameters.  For  example,  the  ICL  commands,  RECLASSIFY_MF  and 
RECLASSIFY_TERM,  have  the  same  syntax  and  semantics,  except  the  former  operates  on  a 
message  file,  whereas  the  latter  operates  on  a  terminal.  To  simplify  and  shorten  the 
specifications,  we  use  a  single  form  to  define  such  commands. 

To  accomplish  this,  we  have  constructed  the  hierarchy  of  data  types  shown  in  Figure  1.  In 
the  figure,  an  arrow  pointing  from  data  type  “a”  to  data  type  “b”  indicates  that  “a”  inherits 
the  properties  of  “b”;  we  refer  to  “b”  as  a  donor  of  “a”.  The  most  abstract  data  type  in  Fig¬ 
ure  1,  i.e.,  the  data  type  with  the  fewest  properties,  is  the  lowest  in  the  hierarchy,  namely, 
“entity”.  Every  other  data  type  shown  possesses  both  its  own  associated  properties  and  proper¬ 
ties  inherited  from  its  donors.  Thus  the  type  “draft  message”  has  the  properties  of  “draft  mes¬ 
sage”,  of  “message”,  and  of  “entity”.  This  means,  for  example,  that  a  draft  message  in  M2  is  a 
container  (because  every  message  in  M2  is  a  container)  and  that  a  draft  message  has  a 
classification  (because  every  entity  has  a  classification). 

Among  the  properties  associated  with  each  data  type  in  Figure  1  is  a  set  of  ICL  com¬ 
mands.  In  addition,  each  data  type  potentially  inherits  each  ICL  command  associated  with  its 
donors.  We  say  potentially  because  each  data  type  above  “entity”  may  only  inherit  some  of  the 
ICL  commands  associated  with  “entity”.  Consider,  for  example,  the  ICL  commands,  UPDATE 
and  RECLASSIFY,  both  of  which  are  associated  with  the  data  type  “entity”.  In  M2,  “draft 
message”  inherits  UPDATE  but  does  not  inherit  RECLASSIFY,  since  draft  messages  in  M2  may 
be  modified  but  not  reclassified.  We  note,  however,  that  a  data  type  always  inherits  all  ICL 
commands  associated  with  donors  other  than  “entity”. 

Table  3  lists  the  data  type  “user”  as  well  as  each  data  type  shown  in  Figure  1,  the  ICL 
commands  with  which  the  data  type  is  associated,  and  the  number  of  the  subsection  in  which 
the  ICL  commands  are  specified.  Within  each  subsection,  the  ICL  commands  are  specified  in  the 
order  presented  in  Table  2. 

A  few  of  the  entries  in  Table  3,  e.g.,  “informal  draft  message”,  have  no  associated  ICL 
commands.  Such  data  types  inherit  all  of  their  ICL  commands  from  donor  data  types.  Thus, 
for  example,  “informal  draft  message”  inherits  the  ICL  commands  associated  with  “draft  mes¬ 
sage”  and  “message”  along  with  the  subset  of  ICL  commands  associated  with  “entity”  that  are 
inherited  by  “message”  and  “draft  message”. 


3.5.  Commands  on  directory 


3.5.1. 

Generic  Name 

DISPLAY  Specific  ICL  Cmds  DISPLAY_MFD 

DISPLAY_TFD 

Input  Pars 

dname:directory  ref 

Output  Pars 

^classification 
sequence  of 

(r:ref,cl:classification[,ccr:booleanl) 

Constraints 

None. 

Description 

Displays  the  name,  classification,  and,  if  the  directory  is  a 
message  file  directory,  the  OCR  mark  of  each  entity  in 
the  directory  named  dname.  Also  displays  the 
classification  c  of  the  directory. 

3.5.2. 

Generic  Name 

PRINT  Specific  ICL  Cmds  PRINTJVIFD 

PRINT_TFD 

Input  Pars 

dname:directory  ref 

Output  Pars 

^classification 
sequence  of 

(r:ref,cl:classification[,ccr:booleanj) 

Constraints 

None. 

Description 

Prints  the  name,  classification,  and,  if  the  directory  is  a 
message  file  directory,  the  CCR  mark  of  each  entity  in 
the  directory  named  dname.  Also  prints  the 
classification  c  of  the  directory. 

3.4.3. 


Generic  Name 

COPYTOENT  Specific  ICL  Cmds  COPYTOENT.TF 

Input  Pars 

tname:text  file  ref 
enamerentity  ref 

Output  Pars 

- 

Constraints 

None. 

Description 

Appends  a  copy  of  each  object  in  tname  to  the  entity 
ename.  Each  new  object  retains  the  value  and 
classification  of  the  corresponding  object  in  tname.  The 
data  type  of  each  new  object  may  have  a  different  data 
type  than  the  corresponding  object  in  tname,  since  the 
object  type  must  be  consistent  with  the  entity  into  which 
the  new  object  is  being  inserted. 

3.4.4. 


Generic  Name 

DUP  Specific  ICL  Cmds  DUP_TF 

Input  Pars 

tnamel:text  file  ref 
tname2:char  string 

Output  Pars 

- 

Constraints 

The  new  text  file  cannot  be  created  if  a  text  file  with 
reference  tname2  already  exists  in  the  user’s  text  file 
directory. 

Description 

Creates  a  new  text  file  that  is  a  duplicate  of  the  text  file 
tnamel.  The  new  text  file  contains  a  copy  of  each  para¬ 
graph  in  tnamel.  The  new  text  file  has  the  reference 
tname2  and  the  same  classification  and  access  set  as 
tnamel.  Inserts  text  file  tname  into  the  user’s  text  file 
directory. 
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3.4.  Commands  on  text  file 


3.4.1. 


f 

I  Generic  Name  CREATE  Specific  ICL  Cmds  CREATE_TF 


Input  Pars 

tname:char  string 
^classification 

as:access  set 

Output  Para 

tf:text  file  val 
^classification 

Constraints 

The  new  text  file  cannot  be  created  if  a  text  file  with 
reference  tname  already  exists  in  the  user’s  text  file 
directory. 

Description 

Creates  a  text  file  with  reference  tname,  classification  c, 
and  access  set  as.  (The  MMS  provides  a  default  access 
set;  in  M2,  the  user  can  later  modify  the  access  set  using 
EDITAS_TF  and  UPDATEAS_TF.)  Inserts  text  file 
tname  in  the  user’s  text  file  directory.  Displays  the  value 
tf  of  the  new  text  file  and  its  classification  c.  The  user  is 
permitted  to  edit  the  displayed  text  file. 

3.4.2. 

Generic  Name 

COPYFRENT  Specific  ICL  Cmds  COPYFRENT_TF 

Input  Pars 

ename:entity  ref 
tname:text  file  ref 

Output  Pars 

- 

Constraints 

None. 

Description 

Appends  a  copy  of  the  entity  ename  to  the  text  file 
tname.  If  the  entity  ename  is  an  object,  the  new  entity 
has  the  same  value  and  classification  as  ename  but  has 
‘paragraph’  as  its  data  type.  If  the  entity  ename  is  a  se¬ 
quence  of  objects,  each  new  object  has  the  same  value 
and  classification  as  its  counterpart  object  but  has  ‘para¬ 
graph’  as  its  data  type. 

Generic  Name  DUP 


Specific  ICL  Cmds  DUP_MF 


Input  Pars  mfnamel. message  file  ref 
mfname2:char  string 

Output  Pars 

Constraints  The  new  message  file  cannot  be  created  if  a  message  file 
with  reference  mfname2  already  exists  in  the  user’s  mes¬ 
sage  file  directory. 

Description  Creates  a  new  message  file  that  is  a  duplicate  of  the  mes¬ 
sage  file  mfnamel.  The  new  message  file  has  the  refer¬ 
ence  mfname2  and  the  same  classification,  CCR-mark, 
and  access  set  as  mfnamel.  Creates  a  copy  of  each  en¬ 
try  in  message  file  mfnamel  and  inserts  the  entry  in 
message  file  mfname2.  New  copies  of  the  messages  asso¬ 
ciated  with  the  entries  are  NOT  created.  The  new  en¬ 
tries  point  to  the  same  message  copies  as  the  existing  en¬ 
tries.  Inserts  message  file  mfname  into  the  user’s  mes¬ 
sage  file  directory. 


Generic  Name 

EXPUNGE 

Specific  ICL  Cmds  EXPUNGE_MF 

Input  Pars 

mfname :message  file  ref 

Output  Pars 

- 

Constraints 

None. 

Description 

Removes  all  message  entries  marked  ‘deleted’  from  the 
message  file  mfname.  Maintains  the  order  of  the 
remaining  message  entries. 

3.3.7. 

Generic  Name 

COPYME 

Specific  ICL  Cmds  COPYME_MF 

Input  Pars 

mename  :message  entry  ref 
mfname:message  file  ref 

Output  Pars 

- 

Constraints 

None. 

Description 

Appends  a  copy  of  the  message  entry  mename  to  the 
message  file  mfname.  The  new  entry  in  mfname  is 
marked  ‘new’. 

3.3.8* 

Generic  Name 

MOVEME 

Specific  ICL  Cmds  MOVEME_MF 

Input  Pars 

mename:message  entry  ref 
mfname:message  file  ref 

Output  Pars 

- 

Constraints 

None. 

Description 


Appends  a  copy  of  the  message  entry  mename  to  the 
message  file  mfname.  Marks  ‘deleted’  the  message  entry 
mename.  The  new  entry  in  mfname  is  marked  ‘new’. 


Generic  Name  PRINT 


Specific  ICL  Cmda  PRINT_MF 


Input  Para 
Output  Para 

Conatrainta 

Deacription 


mfname:message  file  ref 
f:filter 

mf: message  file  val 
or  subset 
c  classification 

None. 

Prints  the  value  of  all  message  entries  in  the  message  file 
mfname  that  satisfy  the  filter  f.  Also  prints  the 
classification  c  of  the  message  file. 


Generic  Name 

DELETEME 

Specific  ICL  Cmda  DELETEME_MF 

Input  Para 

mename:message  entry  ref 

Output  Para 

- 

Conatrainta 

None. 

Deacription 

Marks  ‘deleted’  the  message  entry  mename. 

Generic  Name 

UNDELETEME 

Specific  ICL  Cmda  UNDELETEME_MF 

Input  Para 

mename.message  entry  ref 

Output  Para 

- 

Conatrainta 

None. 

Deacription 

Removes  the  ‘deleted’  mark  from  the  message  entry 

mename. 

3.3.  Command*  on  message  file 


3.3.1. 


Generic  Name 

CREATE  Specific  ICL  Cmds  CREATE_MF 

Input  Pars 

mfnameichar  string 
c  classification 
ccr:boolean 
as:access  set 

Output  Pars 

- 

Constraints 

The  new  message  file  cannot  be  created  if  a  message  file 
with  reference  mfname  already  exists  in  the  user’s  mes¬ 
sage  file  directory. 

Description 

Creates  a  message  file  with  reference  mfname, 
classification  c,  CCR  mark  ccr,  and  access  set  as.  (In  all 
three  family  members,  the  MMS  provides  a  default  access 
set;  in  M2,  the  user  can  later  modify  the  access  set  using 
EDITAS_MF  and  UPDATEAS_MF.)  The  new  message 
file  contains  no  entries.  Inserts  message  file  mfname  in 
the  user’s  message  file  directory. 

3.3.2. 


Generic  Name 

DISPLAY  Specific  ICL  Cmds  DISPLAY_MF 

Input  Pars 

mfname:message  file  ref 

f:filter 

Output  Pars 

mfimessage  file  val 

or  subset 

^classification 

Constraints 

None. 

Description 

Displays  the  value  of  all  message  entries  in  the  message 

file  mfname  that  satisfy  the  filter  f.  Also  displays  the 

classification  c  of  the  message  file. 

3.2.7. 


Generic  Name 

DISPLAYAS 

Specific  ICL  Cmds  DISPLAYAS_MF 
DISPLAY AS_TF 
DISPLAYAS_MSG 
DISPLAYAS_MFD 
DISPLAYAS.TFD 

Input  Pars 

ename  :entity  ref 

Output  Pars 

accsetiaccess  set 

Constraints 

The  type  of  the  entity  ename  is  message  file,  text  file, 
message,  message  file  directory,  or  text  file  directory. 

Description 

Displays  the  access  set  accset  of  the  entity  ename.  The 
user  is  not  allowed  to  modify  the  access  set. 

3.2.8. 

Generic  Name 

PRINTAS 

Specific  ICL  Cmds  PRINTAS  _MF 
PRINTAS_TF 
PRINTAS_MSG 
PRINTAS_MFD 
PRINTAS_TFD 

Input  Pars 

ename:entity  ref 

Output  Pars 

accsetiaccess  set 

Constraints 

The  type  of  the  entity  ename  is  message  file,  text  file, 
message,  message  file  directory,  or  text  file  directory. 

Description  Prints  the  access  set  accset  of  the  entity  ename. 


Generic  Name 

EDIT 

Specific  ICL  Cmds  EDIT_MSG 
EDIT.TF 

Input  Pars 

enamerentity  ref 

Output  Pars 

ent:entity  val 
^classification 

Constraints 

The  type  of  the  entity  ename  is  draft  message  or  text 
file. 

Description 

Displays  the  value  ent  and  the  classification  e  of  the  en¬ 
tity  ename.  The  user  is  permitted  to  edit  the  displayed 
entity. 

3.2.5. 


Generic  Name 

UPDATE  Specific  ICL  Cmds  UPDATE_MSG 

UPDATE_TF 

.1  put  Pars 

ename:entity  ref 
ent:entity  val 

Output  Pars 

- 

Constraints 

The  type  of  the  entity  ename  is  draft  message  or  text 
file. 

Description 

Sets  the  value  of  the  entity  ename  to  ent. 

3.2.0. 


Generic  Name  RECLASSIFY 

Input  Pars  ename:entity  ref 

^classification 


Specific  ICL  Cmds  RECLASSIFY_MF 
RECLASSIFY.TF 
RECLASSIFY.TERM 


Output  Pars 

Constraints  The  type  of  the  entity  ename  is  message  file,  text  file,  or 
terminal. 


Description 


Assigns  the  classification  c  to  the  entity  ename. 


3.2.  Commands  on  entity 


3.2.1. 


Generic  Name 

DESTROY  Specific  ICL  Cmds  DESTROY_MF 

DESTROY.TF 

DESTROY.TERM 

Input  Para 

ename:entity  ref 

Output  Para 

- 

Constraints 

The  type  of  the  entity  ename  is  message  file,  text  file,  or 
terminal. 

Description 

Destroys  the  entity  ename.  Removes  the  entity  from 
any  containers  that  contain  it. 

3.2.2. 


Generic  Name 

DISPLAY 

Specific  ICL  Cmds  DISPLAY_MSG 
DISPLAY_TF 

Input  Pars 

ename:entity  ref 

Output  Pars 

ent:entity  val 
c  classification 

Constraints 

The  type  of  the  entity  ename  is  message  or  text  file. 

Description 

Displays  the  value 

ent  and  the  classification  c  of  the  en- 

tity  ename.  The 
displayed  entity. 

user  is  not  permitted  to  edit  the 

3.2.3. 


Generic  Name 

PRINT  Specific  ICL  Cmds  PRINT_MSG 

PRINT.TF 

Input  Pars 

ename:entity  ref 

Output  Pars 

ent:entity  val 
^classification 

Constraints 

The  type  of  the  entity  ename  is  message  or  text  file. 

Description 

Prints  the  value  ent  and  the  classification  c  of  the  entity 

ename. 

3.1.2.  Form  Used  to  Specify  the  ICL  Commands 

Each  form  lists  the  one  or  more  ICL  commands  to  which  it  applies  and  provides  a  generic 
name  for  the  commands.  The  sections  of  the  form  named  “Input  Pars”  and  “Output  Pars”  indi¬ 
cate  the  command  parameters.  The  user  provides  the  input  parameters  along  with  the  com¬ 
mand  name  (the  user  interface  may  provide  defaults  for  some  of  the  input  parameters).  The 
output  parameters  identify  the  items  that  are  displayed  at  the  user  terminal  or  output  by  a 
printer.  Each  parameter  is  expressed  as  “x:y”,  where  x  is  the  parameter  and  y  is  the  attribute 
type  (e.g.,  classification,  access  set)  or  the  data  type  of  the  parameter.  The  “Description”  sec¬ 
tion  gives  a  prose  description  of  the  command  semantics.  The  “Constraints”  section  defines  any 
constraints  on  the  command’s  input  parameters.  In  particular,  this  section  identifies  the  specific 
data  types  that  inherit  the  ICL  commands  associated  with  the  data  type  “entity”. 

The  successful  completion  of  each  ICL  command  requires  that  the  preconditions  described 
in  the  MMS  security  model  and  various  message  system  preconditions  are  satisfied.  This  docu¬ 
ment  does  not  include  the  security  model  preconditions  nor  a  complete  statement  of  the  message 
system  preconditions.  A  complete  statement  of  these  preconditions  will  be  included  in  a  future 
report.  However,  we  do  list  below  three  preconditions  that  all  ICL  commands  must  enforce: 

(a)  Each  input  parameter  must  have  the  type  defined  in  the  “Input  Pars”  section  and 
must  satisfy  the  conditions  listed  in  the  “Constraints”  section. 

(b)  Each  reference/userlD  supplied  as  an  input  parameter  must  refer  to  an  existing 
entity /user. 

(c)  To  invoke  any  command  other  than  the  LOGIN  command,  the  user  must  be  logged 
in  to  some  terminal. 

Any  ICL  command  that  does  not  satisfy  the  required  preconditions  cannot  be  completed. 

The  following  abbreviations  are  used  in  the  specifications: 


Abbreviation 

Meaning 

ref 

reference 

char 

character 

setof 

set  of 

val 

value 
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Table  3:  MMS  Data  Types  and  Their  Associated  ICL  Commands 


Data  Type 

Section 

ICL  Commands 

entity 

3.2 

DESTROY,  DISPLAYRRINT, 

EDIT, UPDATE, RECLASSIFY, 

DISPLAYAS,PRINTAS,EDITAS, 

UPDATEAS 

message  file 

3.3 

CREATE, DISPLAY, PRINT, 
DELETEME.UNDELETEME  .EXPUNGE, 
COPYME,MOVEME,DUP 

text  file 

3.4 

CREATE, COPYFRENT,COPYTOENT, 
DUP 

directory 

3.5 

DISPLAY  ,PRINT 

message  file 

, 

None 

directory 

text  file 

None 

directory 

terminal 

3.6 

CREATE, DISPLAY, PRINT  MAXCLAS 

message 

3.7 

DUP 

draft  message 

3.8 

CREATE, SEND 

sent  message 

3.9 

REPLY, FORINFO 

formal  draft  message 

3.10 

FORCOORD,FORRELEASE 

formal  sent  message 

3.11 

FORACTION, READDRESS 

informal  draft  message 

_ 

None 

informal  sent  message 

- 

None 

user 

3.12 

CREATEDESTROY, DISPLAY, 

PRINT, CHGCLEAR,CHGPW, 

ADDAROLE.RMVAROLE, 

ADDCROLE,RMVCROLE, 

LOGIN  .LOGOUT 

3.0.  Commands  on  terminal 
3.8.1. 


Generic  Name 

CREATE  Specific  ICL  Cmds  CREATE_TERM 

Input  Pars 

tname:char  string 
^classification 

as:access  set 

Output  Pars 

- 

Constraints 

The  new  terminal  cannot  be  created  if  a  terminal  with 
reference  tname  already  exists. 

Description 

Creates  a  terminal  with  reference  tname,  maximum 
classification  c,  and  access  set  as.  (The  MMS  provides  a 
default  access  set  that  is  not  user-visible.) 

3.6.2. 


Generic  Name 

DISPLAY 

Specific  ICL  Cmds  DISPLAY_TERM 

Input  Pars 

tname:terminai  ref 

Output  Pars 

^classification 

c2:classification 

Constraints 

None. 

Description 

Displays  the  maximum  classification  cl  and  the  current 
classification  c2  of  the  terminal  tname. 

3.6.3. 

Generic  Name  PRINT  Specific  ICL  Cmds  PRINT_TERM 

Input  Pars  tname:terminal  ref 

Output  Pars  cl  classification 

c2:classification 

Constraints  None. 

Description  Prints  the  maximum  classification  cl  and  the  current 

classification  c2  of  the  terminal  tname. 


Generic  Name  MAXCLAS 


Specific  ICL  Cmds  MAXCLAS.TERM 


Input  Pars  tname:terminal  ref 

^classification 

Output  Pars 
Constraints  None. 

Description  Sets  the  maximum  classification  of  the  terminal  tn&me 

to  c. 


Generic  Name  DUP 


Specific  ICL  Cmds  DUP_MSG 


Input  Pars 

Output  Pars 

Constraints 

Description 


msgidimessage  ref 
mfna me: message  file  ref 

dmsg:draft  message  val 
^classification 

None. 

Creates  a  copy  of  the  message  msgid.  The  new  message 
has  a  new  reference  in  its  ID  field  and  the  same 
classification,  the  same  message  type  (e.g.,  formal  or  in¬ 
formal),  and,  if  the  original  message  is  a  draft  message, 
the  same  access  set  as  the  original  message;  the  userlD  or 
role  of  the  user  who  created  the  message  is  in  the  From 
field;  and  the  creating  user’s  site  is  in  the  Originator  field. 
Creates  a  message  entry  for  the  new  message  and  ap¬ 
pends  it  to  the  message  file  mfn&me.  The  new  entry  is 
marked  ‘new’.  Displays  both  the  value  dmsg  and  the 
classification  c  of  the  new  message.  The  user  is  permitted 
to  modify  the  displayed  message. 


3.8.  Commands  on  draft  message 


3.8.1. 


Generic  Name 

CREATE  Specific  ICL  Cmds  CREATE_MSG 

Input  Pars 

trmessage  type 
^classification 
as:access  set 
mfname:message  file  ref 

Output  Pars 

dmsg:draft  message  val 
^classification 

Constraints 

None. 

Description 

Creates  a  draft  message  of  message  type  t,  classification 
c,  and  access  set  as.  (The  MMS  provides  a  default  access 
set;  in  M2,  the  user  can  later  modify  the  access  set  using 
EDITAS_MSG  and  UPDATEAS-MSG.)  Creates  a  mes¬ 
sage  entry  for  the  new  message  and  appends  it  to  the 
message  file  mfname.  The  new  entry  is  marked  ‘new’. 

Displays  the  value  dmsg  and  the  classification  c  of  the 
new  message.  The  new  message  has  a  reference  assigned 
by  the  MMS  in  its  ID  field,  the  userlD  or  role  of  the  user 
who  created  the  message  in  its  From  field,  and  the  user’s 
site  in  its  Originator  field.  The  user  is  permitted  to  edit 
the  displayed  message. 

3.8.2. 

Generic  Name 

SEND  Specific  ICL  Cmds  SEND_MSG 

Input  Pars 

msgid.draft  message  ref 

Output  Pars 

- 

Constraints 

None. 

Description 

Sends  the  draft  message  msgid  to  all  addressees  listed  in 
the  address  fields  of  the  message.  The  message  type  is 
changed  from  draft  message  to  sent  message.  The  sent 
message  is  assigned  a  new  ID.  For  each  local  addressee, 
the  MMS  creates  a  message  entry  for  the  message  and 
appends  the  entry  to  the  user’s  inbox,  marking  it  ‘new’. 

For  each  remote  addressee,  the  MMS  may  transmit  a 
copy  of  the  message  over  the  appropriate  network. 

3.9.  Commands  on  sent  message 


3.9.1. 


Generic  Name 

REPLY  Specific  ICL  Cmds  REPLY_MSG 

Input  Part 

msgid:sent  message  ref 
t:message  type 
^classification 
as:access  set 
mfname:message  file  ref 

Output  Pars 

dmsg:draft  message  val 
^classification 

Constraints 

None. 

Description 

Creates  a  message  of  message  type  t,  classification  c,  and 
access  set  as.  Creates  a  message  entry  for  the  message 
and  appends  it  to  the  message  file  mfname.  The  new 
entry  is  marked  ‘new’.  Displays  the  value  dmsg  of  the 
new  message.  The  new  message  has  a  reference  assigned 
by  the  MMS  in  its  ED  field,  the  userlD  or  role  of  the  user 
who  created  the  message  in  its  From  field,  the  contents  of 
the  From  field  of  the  message  msgid  in  the  To  field,  and 
the  same  Subject  field  as  msgid.  Also  displays  the  mes¬ 
sage  classification  c.  The  user  is  allowed  to  edit  the  new 

message. 

3.9.2. 


Generic  Name 

FORINFO  Specific  ICL  Cmds  FORINFO_MSG 

Input  Pars 

msgid:sent  message  ref 

A:setof(  addressee) 

Output  Pars 

- 

Constraints 

None. 

Description 

For  formal  messages,  forwards  for  “info”  the  message 
msgid  to  all  addressees  in  A.  For  informal  messages, 
forwards  the  message  msgid  to  all  addressees  in  A.  For 
each  user  in  A,  creates  a  message  entry  for  the  message 
and  appends  the  entry  to  the  user’s  inbox.  The  entry  has 
the  ‘for  info’  mark  and  a  ‘new’  mark. 

3.10.  Commands  on  formal  draft  message 


3.10.1. 


Generic  Name 

FORCOORD  Specific  ICL  Cmds  FORCOORD_MSG 

Input  Pars 

msgidiformal  draft 

message  ref 

A:setof(addressee) 

Output  Pars 

- 

Constraints 

None. 

Description 

Forwards  the  formal  draft  message  msgid  to  all  addres¬ 
sees  in  A.  The  data  type  of  msgid  does  not  change.  For 
each  user  in  A,  creates  an  entry  for  the  message  and  ap¬ 
pends  it  to  the  user’s  inbox.  The  entry  has  the  ‘for  coord’ 
mark  and  a  ‘new’  mark.  Each  addressee  may  either  send 
comments  on  the  message  via  another  message  or,  if  the 
addressee  has  “update”  permission,  he  may  modify 
msgid. 

3.10.2. 


Generic  Name 

FORREL.EASE  Specific  ICL  Cmds  FORRELEASE_MSG 

Input  Pars 

msgid:formal  draft 

message  ref 

a:addressee 

Output  Pars 

- 

Constraints 

None. 

Description 

The  formal  draft  message  msgid  is  forwarded  to  the  ad¬ 
dressee  a  for  release.  The  user  who  receives  the  message 
“for  release”  has  a  new  entry  for  the  message  in  his  in¬ 
box;  the  entry  has  the  'for  release’  mark  and  a  ‘new’ 
mark. 

3.11.  Commands  on  formal  sent  message 


3.11.1. 


Generic  Name 

FORACTION' 

Specific  ICL  Cmda  FORACTION_MSG 

Input  Para 

msgid:formal  sent 
message  ref 
A:setof(addressee) 

Output  Para 

- 

Conatrainta 

None. 

Deaeription 

Forwards  for  “action”  the  formal  sent  message  msgid  to 
each  addressee  in  A.  For  each  user  in  A,  creates  an  en¬ 
try  for  the  message  and  appends  it  to  the  user’s  inbox. 

The  entry  has  the  ‘for  action’  mark  and  a  ‘new’  mark. 

3.11.2. 


Generic  Name 

READDRESS  Specific  ICL  Cmda  READDRESS_MSG 

Input  Para 

msgid:formal  sent 

message  ref 

mfnamermessage  file 

ref 

Output  Para 

dmsgrdraft  message  val 
^classification 

Conatrainta 

None. 

Deaeription 

Creates  a  copy  of  the  sent  formal  message  msgid.  The 
new  formal  draft  message  has  the  same  value  as  msgid, 
namely,  dmsg;  the  same  classification  as  msgid,  namely, 
c;  a  reference  assigned  by  the  MMS  in  its  ID  field;  and 
the  same  message  type  as  msgid.  Creates  a  message  en¬ 
try  for  the  new  message  and  appends  it  to  the  message 
file  mfhame.  The  user  is  only  permitted  to  fill  in  the  ad¬ 
dress  fields  of  the  new  message. 

3.12.  Commands  on  user 


Generic  Name 

CREATE  Specific  ICL  Cmds  CREATE.USER 

Input  Pars 

uid:char  string 

pw:password 

chclearance 

A:setof(role) 

Output  Pars 

- 

Constraints 

The  new  user  cannot  be  created  if  there  already  exists  a 
user  with  userlD  uid. 

Description 

Creates  a  user  with  userlD  uid,  password  pw,  clearance 
cl,  and  the  authorized  roles  in  A.  Also  creates  a  message 
file  directory,  a  text  file  directory,  an  inbox  for  the  new 
user,  and  initial  access  sets  for  the  directories  and  the  in¬ 
box. 

3.12.2. 


Generic  Name  DESTROY 
Input  Pare  uid:userID 

Output  Pars 
Constraints  None. 


Specific  ICL  Cmds  DESTROY.USER 


Description  Destroys  the  user  uid.  Also  destroys  the  user’s  message 
file  directory,  text  file  directory,  and  inbox.  Any  message 
files  or  text  files  that  are  solely  in  this  user’s  directories 
are  also  destroyed. 


3.12.3. 


Generic  Name 

DISPLAY  Specific  ICL  Cmds  DISPLAY.USER 

Input  Pars 

uid:userID 

Output  Pars 

cl:clearance 

A:setof(role) 

B:setof(role) 
tname:terminal  ref 

Constraints 

None. 

Description 

Displays  the  clearance  cl  of  user  uid,  his  set  of  author¬ 
ized  roles  A,  and,  if  uid  is  logged  on,  his  set  of  current 
roles  B  and  the  terminal  tname  that  he  is  logged  onto. 

Only  the  system  security  officer  is  permitted  to  execute 
this  command. 

Generic  Name 

PRINT  Specific  ICL  Cmds  PRINT.USER 

Input  Pars 

uid:userID 

Output  Pars 

cl.clearance 

A:setof(role) 

B:setof(role) 
tnamerterminal  ref 

Constraints 

None. 

Description 

Prints  the  clearance  cl  of  user  uid,  his  set  of  authorized 
roles  A,  and,  if  uid  is  logged  on,  his  set  of  current  roles  B 
and  the  terminal  tname  that  he  is  logged  onto.  Only  the 
system  security  officer  is  permitted  to  execute  this  com¬ 
mand. 

T 


Generic  Name  CHGCLR 


Specific  ICL  Cmdt  CHGCLR_USER 


Input  Pare 

Output  Pars 

Constraints 

Description 


uid:userID 

clxlearance 

None. 

Changes  the  clearance  of  the  user  uid  to  el. 


3.12.8. 


Generic  Name  CHGPW 


Input  Pars 

Output  Pars 
Constraints 

Description 


Specific  ICL  Cmds  CHGPW.USER 


uid:userID 
oldpw:password 
newpw  password 


A  precondition  for  this  command  is  that  the  old  value  of 
the  password  is  oldpw.  (The  system  security  officer  need 
not  provide  the  old  password.) 

Changes  the  password  of  the  user  uid  to  newpw. 


3.12.7. 


Generic  Name 
Input  Pars 

Output  Pars 
Constraints 


ADDAROLE 

uid:userID 

A:setof(role) 

None. 


Specific  ICL  Cmds  ADDAROLE.USER 


Description 


Adds  the  roles  in  A  to  the  set  of  roles  authorized  for  the 
user  uid. 


Generic  Name 

RMVAROLE  Specific  ICL  Cmds  RMVAROLEJJSER 

Input  Para 

uidruserlD 

A:setof(role) 

Output  Pars 

- 

Constraints 

None. 

Description 

Removes  the  roles  in  A  from  the  set  of  roles  authorized 

for  the  user  uid. 

3.12.9. 


Generic  Name 

ADDCROLE 

Specific  ICL  Cmds  ADDCROLE_USER 

Input  Pars 

uidruserlD 

A:setof(role) 

Output  Pars 

- 

Constraints 

None. 

Description 

Adds  the  roles  in 
for  the  user  uid. 

A  to  the  set  of  current  roles  authorized 

3.12.10. 


Generic  Name 

RMVCROLE 

Specific  ICL  Cmds  RMVCROLE_USER 

Input  Pars 

uidruserlD 

A:setof(role) 

Output  Pars 

- 

Constraints 

None. 

Description 

Removes  the  roles  in  A  from  the  set  of  current  roles  au- 

thorized  for  the 

user  uid. 

3.12.11. 


Generic  Name 

LOGIN  Specific  ICL  Cmda  LOGIN.USER 

Input  Pars 

tname:terminal  ref 
uid:userID 
pw-.password 
^classification 

A:setof(role) 

Output  Pars 

- 

Constraints 

None. 

Description 

Logs  the  user  with  userED  uid  and  password  p-w  onto  the 
terminal  tname.  Sets  the  classification  of  the  terminal 
to  c.  Assigns  the  roles  in  A  as  the  current  roles  assigned 
to  the  user.  Fixes  the  access  set  of  tname  so  that  the 
user  uid  can  RECLASSIFY  the  terminal  and  LOGOUT 
of  the  terminal. 

Generic  Name  LOGOUT 


Specific  ICL  Cmda  LOGOUT_USER 


Input  Para  uid:userID 

tname:terminal  ref 

Output  Para 


Conatrainta 


None. 


Deacription  Logs  the  user  with  userDD  uid  off  of  the  terminal  tname. 

Fixes  the  access  set  of  the  terminal  so  that  the  user  uid 
can  no  longer  RECLASSIFY  or  LOGOUT  of  the  terminal. 
Removes  all  message  entries  marked  ‘deleted’  from  each 
of  the  user’s  message  files.  Removes  the  ‘new’  mark  from 
each  entry  that  is  marked  ‘new’.  Sets  the  user’s  current 
role  set  to  the  empty  set. 


4.  Glossary 

This  section  provides  definitions  for  terms  used  in  this  report.  In  particular,  terms  that 
appear  as  parameters  to  ICL  commands  are  defined.  Many  of  the  definitions  have  been 
extracted  from  the  MMS  security  model  flj . 

access  set:  a  set  of  triples  associated  with  an  entity.  Each  triple  consists  of  a  userlD 

or  role,  an  operation,  and  an  operand  index.  If  a  given  operation  requires 
more  than  one  operand,  the  operand  index  specifies  the  position  in  which 
a  reference  to  this  entity  may  appear  as  an  operand.  The  existence  of  a 
particular  triple  in  the  access  set  implies  that  a  user  corresponding  to  the 
userlD  or  role  is  authorized  to  invoke  the  specified  operation  on  the  entity 
with  which  the  access  set  is  associated. 


address  field: 


addressee: 
authorized  role: 


classification: 


clearance: 


container: 


current  role: 


draft  message: 


entity. 

filter: 


formal  message: 


inbox: 


a  field  of  a  message  that  contains  addresses.  The  To  field,  the  CC  field, 
and  the  From  field  are  examples  of  address  fields. 

a  userlD,  a  role,  or  an  organization  to  whom  a  message  can  be  sent. 

a  role  that  the  user  is  authorized  for.  The  system  security  officer  assigns 
the  user’s  set  of  authorized  roles. 

a  designation  reflecting  the  damage  that  could  be  caused  by  unauthorized 
disclosure  of  information.  Includes  a  sensitivity  level  (UNCLASSIFIED, 
CONFIDENTIAL,  SECRET,  TOP  SECRET),  and  a  set  of  zero  or  more 
compartments  (CRYPTO,  NUCLEAR,  etc.). 

the  degree  of  trust  associated  with  a  person,  expressed  in  the  same  way 
as  a  classification.  In  a  secure  MMS,  each  user  will  have  a  clearance. 

a  unit  of  information  that  has  a  classification  and  that  may  contain 
objects  and/or  other  containers  each  with  their  own  classification.  Unlike 
an  object,  a  container  can  be  multilevel. 

an  attribute  of  a  container.  CCR  is  an  abbreviation  for  Container  Clear¬ 
ance  Required.  CCR  containers  require  that  a  user  who  wishes  to  view 
information  in  a  container  have  a  clearance  that  exceeds  or  equals  the 
classification  of  the  container. 

a  role  that  the  user  has  at  a  given  time.  The  user’s  set  of  current  roles  is 
a  subset  of  his  set  of  authorized  roles.  The  user  defines  his  set  of  current 
roles. 

a  message  in  draft  form.  Draft  messages  are  messages  that  users  create 
and  edit.  The  SEND31SG  command  converts  a  draft  message  into  a 
sent  message,  distributing  the  latter  to  its  addressees. 

an  object  or  a  container. 

a  set  of  criteria.  To  satisfy  a  filter,  a  message  entry  must  satisfy  all  the 
criteria  of  the  filter.  An  example  of  a  filter  is  ALL;  every  message  entry 
satisfies  the  filter  ALL. 

a  class  of  messages  that  are  exchanged  by  military  organizations  rather 
than  by  individuals.  Such  messages  are  always  “on  the  record”  and  are 
stored  for  lengthy  periods  after  their  transmission.  They  contain  special 
fields,  such  as  Info  and  Precedence.  Special  operations,  e.g., 
FORACTION3ISG,  F0RINF03ISG,  and  READDRESS31SG ,  may  be 
applied  to  formal  messages.  Only  users  authorized  for  the  role  “releaser” 
can  releas  a  formal  message. 

a  message  file  in  which  the  MMS  inserts  each  message  that  is  sent  to  a 
given  user.  Every  user  has  an  inbox. 
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informal  message: 


message: 


message  entry: 
message  file: 


a  class  of  messages  that  are  exchanged  by  individuals.  Such  messages  are 
‘‘off  the  record”  and  there  is  no  official  requirement  for  retaining  copies. 
They  have  fewer  fields  than  formal  messages  and  fewer  operations  can  be 
applied  to  them. 

a  set  of  fields,  including  To,  From,  Subject,  and  Text.  A  message  is  either 
a  draft  message  or  a  sent  message.  Moreover,  every  message  has  a  mes¬ 
sage  type,  e.g.,  formal. 

consists  of  a  message  and  status  information  about  the  message,  e  g., 
whether  the  message  is  ‘for  action’,  ‘for  release’,  etc. 

a  sequence  of  message  entries. 


message  file  directory:  a  set  of  named  message  files  that  a  user  owns.  Each  user  has  a  single 
message  file  directory. 


message  type: 

object: 

password: 

reference: 

role 


sent  message: 
terminal: 
text  file: 


an  attribute  of  a  message  that  determines  the  fields  that  the  message 
contains,  the  set  of  operations  that  can  be  applied  to  the  message,  and 
whether  the  message  is  “on  the  record”.  In  many  MMSs,  there  are  two 
message  types:  formal  and  informal. 

the  smallest  unit  of  information  in  the  MMS  that  has  a  classification.  An 
object  contains  no  other  objects  and  cannot  be  multilevel. 

a  character  string  that  is  used  to  restrict  usage  of  a  userlD. 

a  name  for  an  entity.  The  reference  may  be  direct,  e.g.,  a  date-time- 
group  coupled  with  an  originator.  A  reference  may  also  be  indirect,  e.g., 
the  "current  message’s  Text  field’s  third  paragraph.” 

the  job  that  the  user  is  performing,  such  as  downgrader,  releaser,  etc.  A 
user  is  always  associated  with  at  least  one  role  at  any  instant,  and  the 
user  can  change  roles  during  a  session.  The  system  security  officer  assigns 
the  user's  set  of  authorized  roles.  Whenever  the  user  is  logged  in,  his  set 
of  current  roles  specifies  the  roles  that  are  valid  at  the  time. 

a  message  that  has  been  released.  The  SENT>_MSG  command  converts  a 
draft  message  into  a  sent  message. 

the  device  onto  which  the  user  logs  in  to  use  the  MMS.  Most  MMS  out¬ 
put  is  displayed  on  the  user’s  terminal. 

a  sequence  of  paragraphs.  A  user  may  save  text,  address  lists,  and  other 
miscellaneous  information  in  text  files. 


text  file  directory:  a  set  of  named  text  files.  Each  user  has  a  single  text  file  directory, 
user:  a  person  authorized  to  use  the  MMS. 

userlD:  a  character  string  used  to  denote  a  user  of  the  system.  To  use  the  MMS, 

a  person  presents  a  userlD  to  the  system,  and  the  system  authenticates 
that  the  person  is  the  user  corresponding  to  that  userlD.  Each  user  has  a 
unique  userlD. 
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APPENDIX 

This  section  provides  an  alphabetical  index  to  the  ICL  command  specifications. 


ICL  Command 

Where  Spec. 

ICL  Command 

Where  Spec. 

ADDAROLE.USER 

3.12.7 

LOGIN_USER 

3.12.11 

ADDCROLEJJSER 

3.12.9 

LOGOUT_USER 

3.12.12 

CHGCLEAR_USER 

3.12.5 

MAXCLAS.TERM 

3.6.4 

CHGPWDJUSER 

3.12.6 

MOVEME_MF 

3.3.8 

COPYME_MF 

3.3.7 

COPYFRENT_MF 

3.4.2 

PRINT_MF 

3.3.3 

COPYTOENT_MF 

3.4.3 

PRINT_MFD 

3.5.2 

CREATE_MF 

3.3.1 

PRINT_MSG 

3.2.3 

CREATE_MSG 

3.8.1 

PRINT_TERM 

3.6.3 

CREATE_TERM 

3.6.1 

PRINT.TF 

3.2.3 

CREATE.TF 

3.4.1 

PRINT.TFD 

3.5.2 

CREATE JLJSER 

3.12.1 

PRINT_USER 

3.12.4 

PRINTAS_MF 

3.2.8 

DELETEME_MF 

3.3.4 

PRINTAS_MFD 

3.2.8 

DESTROY_MF 

3.2.1 

PRINTAS_MSG 

3.2.8 

DESTROY.TERM 

3.2.1 

PRINTAS_TF 

3.2.8 

DESTROY.TF 

3.2.1 

PRINTAS_TFD 

3.2.8 

DESTROY_USER 

3.12.2 

DISPLAY_MF 

3.3.2 

READDRESS_MSG 

3.11.2 

DISPLAY_MFD 

3.5.1 

RECLASSIFY_MF 

3.2.6 

DISPLAY_MSG 

3.2.2 

RECLASSIFY_TERM 

3.2.6 

DISPLAY_TERM 

3.6.2 

RECLASSIFY_TF 

3.2.6 

DISPLAY.TF 

3.2.2 

REPLYJUSG 

3.9.1 

DISPLAY_TFD 

3.5.1 

RMVAROLE.USER 

3.12.8 

DISPLAYJJSER 

3.12.3 

RMVCROLE_USER 

3.12.10 

DISPLAYAS_MF 

3.2.7 

DISPLAY ASJvIFD 

3.2.7 

SEND_MSG 

3.8.2 

DISPLAYAS_MSG 

3.2.7 

DISPLAYAS.TF 

3.2.7 

UNDELETEME31F 

3.3.5 

DISPLAYAS.TFD 

3.2.7 

UPDATEJMSG 

3.2.5 

DUP_MF 

3.3.9 

UPDATE.TF 

3.2.5 

DUP_MSG 

3.7.1 

UPDATEAS_MF 

3.2.10 

DUP_TF 

3.4.4 

UPDATEAS_MFD 

3.2.10 

UPDATEAS_MSG 

3.2.10 

EDIT_TF 

3.2.4 

UPDATEAS.TF 

3.2.10 

EDIT_MSG 

3.2.4 

UPDATEAS.TFD 

3.2.10 

EDITAS_MF 

3.2.9 

EDITAS31FD 

3.2.9 

EDITAS_MSG 

3.2.9 

EDITAS_TF 

3.2.9 

EDITAS_TFD 

3.2.9 

EXPUNGE_MF 

3.3.6 

FORACTION_MSG 

3.11.1 

FORCOORD_MSG 

3.10.1 

FORINFOJdSG 

3.9.2 

FORRELEASE_MSG 

3.10.2 

END 

FILMED 
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